Skip transparent rgba background colors in highlight parse

The new background-color parse rule treats any non-transparent/inherit value as a highlight, but many pasted HTML sources encode “no background” as rgba(0, 0, 0, 0). In that case cssColorToHex drops alpha and returns #000000, so plain text is imported with an unintended black highlight mark. This regression is introduced by the new style-based parse path and will surface on paste inputs that use transparent RGBA values.

Useful? React with 👍 / 👎.

The rgb/rgba parsing is case-sensitive and not anchored to the closing ")", so values like "RGB(255,0,0)" or strings with extra trailing characters won't be converted. Also, channels aren't clamped to 0–255; if a value like "rgb(300,0,0)" is encountered, the generated hex will be longer than 6 digits and invalid. Consider using a case-insensitive, fully-anchored regex and clamping channels to [0,255] before hex conversion.

parseDOM prefers data-color as-is, so any existing content (or copy/paste within SuperDoc) that has data-color="rgb(...)"/"rgba(...)" will still bypass cssColorToHex and reintroduce the original rendering issue. Consider applying cssColorToHex to the data-color value too (and falling back to backgroundColor if it returns null).

The transparent / inherit checks are strict string comparisons on the raw style value. Since style values can vary in casing or include whitespace (and you already trim in cssColorToHex), it’d be safer to normalize value (trim + lowercase) before these checks to avoid accidentally creating a highlight mark for " transparent ", "Transparent", etc.

getAttrs always returns a highlight mark when value is truthy, even if cssColorToHex(value) returns null (e.g. whitespace-only). That would create a highlight mark with color: null, which may lead to unexpected default <mark> styling. Consider computing the converted color first and returning false when the conversion yields null.

JSDoc says this converts to "#RRGGBB" and returns null for empty/invalid input, but the implementation (and tests) currently pass through 3-digit hex and return the original string for any unrecognized value (including invalid colors). Please either tighten validation + normalize to 6-digit hex, or update the docstring to match the actual behavior/contract.

cssColorToHex(value) can return null here -- for example when the pasted HTML has rgba(0, 0, 0, 0) (a common way browsers encode "no background"). That value passes the transparent/inherit guard on line 58, but cssColorToHex correctly returns null for zero-alpha.

The problem is this still returns { color: null }, which tells ProseMirror to create a highlight mark with no color -- a phantom mark in the document.

  getAttrs: (value) => {
    if (!value || value === 'transparent' || value === 'inherit') return false;
    const color = cssColorToHex(value);
    return color ? { color } : false;
  },

Adressed on 36d4a5b

data-color is used as-is without going through cssColorToHex. This matters because SuperDoc sets data-color to whatever the stored color attribute is (line 44). If a document was edited before this fix, the stored value could be rgb(255, 0, 0). When that content is copy-pasted within SuperDoc, the pasted <mark> has data-color="rgb(255, 0, 0)" which gets stored raw.

Downstream, normalizeColor in pm-adapter/src/utilities.ts prepends # to anything that doesn't start with it, producing "#rgb(255, 0, 0)" which breaks rendering in presentation mode.

  parseDOM: (element) => cssColorToHex(element.getAttribute('data-color')) || cssColorToHex(element.style.backgroundColor),

Adressed on 36d4a5b

Minor: the transparent/inherit check here and the null handling inside cssColorToHex are doing related work in two places. If you add the null guard from comment 1, you could simplify this to just:

  getAttrs: (value) => {
    if (!value) return false;
    const color = cssColorToHex(value);
    return color ? { color } : false;
  },

Since cssColorToHex('transparent') would return "transparent" (named color passthrough), you'd want to either keep the explicit check here, or teach cssColorToHex to return null for CSS keywords like transparent/inherit/initial.

Either way works -- just pick one place for that logic.

Adressed on 7a02659.

Chose to keep the logic explictly here so that cssColorToHex can be a bit more agnostic on how to handle those values.

The .replace(/['"]+/g, '') is left over from the previous code -- el.style.color is a browser-computed property that never contains quotes.

Safe to drop it now that you're already editing this line:

parseDOM: (el) => cssColorToHex(el.style.color),

Adressed on 36d4a5b

@returns {string|null} Hex color string or null -- this can also return named colors ("red") and 3-digit hex ("#f00") unchanged, so "Hex color string" isn't quite right.

Something like Normalized color string or null would match the actual contract better.

Addressed on 8611418